Construction of virtual objects based on run-time type information

ABSTRACT

A method for creating object-type specifications for virtual and partially virtual objects is presented wherein virtual objects may specify an external source for their internal state. This virtual state of an object may come from more than one external source. The method is implemented by creating object type specifications for virtual objects, registering object-type specifications for all objects that participate in virtual objects, and providing an object factory where collaborators can obtain virtual objects as needed. With regard to creating object-type specifications for virtual objects, the present invention maps the data item of one object to the data item of another object through the use of a query of run-time type-information (RTTI) to obtain the complete metadata for both objects which must be known.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority from and is acontinuation-in-part of U.S. Provisional Patent Application No.60/233,070, entitled EXTENSIBLE DEVELOPMENT PLATFORM, which was filed onSep. 15, 2000, and is hereby incorporated by reference in its entirety.Additionally, the present application is related to and includes thedisclosure of Assignee's co-pending U.S. Patent Application Ser. No.______, entitled EXTENSIBLE SOFTWARE DEVELOPMENT USING ASYNCHRONOUSMESSAGING (Attorney Docket No. 15016.30), which is hereby incorporatedby reference in its entirety; and Assignee's co-pending U.S. PatentApplication Ser. No. ______, entitled EXTENDED ASYNCHRONOUS MESSAGING(Attorney Docket No. 15016.33), which is hereby incorporated byreference in its entirety.

BACKGROUND OF THE INVENTION

[0002] 1. The Field of the Invention

[0003] This invention generally relates to object-oriented programming,and particularly, objects that are composites of other objects alreadyknown to the system.

[0004] 2. The Relevant Technology

[0005] Software computer programming highly invests in the concept ofre-use of software components. In order to more greatly facilitate suchre-use, programming architectures partition software applications intocomponents or other smaller and more manageable blocks or portions ofsoftware. Furthermore, data elements are reused across multiple codesegments or components for efficiency and for commonality throughout thesoftware program. In an object-oriented programming architecture, suchdata elements have assumed various names including the term “object.”For clarity, differentiation is presented between “objects” thatrepresent things that can be described, such as people, birds, orvehicles; and “objects” that primarily represent a logical oralgorithmic process, such as a “compression provider,” “registrationmanager,” “object store,” etc.

[0006] The objects that represent “things” tend to have a real-worldanalogs and are called “data objects.” The other type of objects areclassified as “logic objects” and may be considered to be components orlogical partitions of computer software generally specializing insolving a limited aspect of the problem being solved. Logic objects,while being thought of as components, may also be thought of as finergrained objects making up the combined logic of a component. For thesake of simplicity, the present discussion does not indulge in thesemantic of whether or not data objects also implement logic.

[0007] In a typical software system, many fine-grained data objectsexist. Often, these data objects make up the consumable artifacts that alogic object uses when collaborating with other logic objects. It isappreciated that in relationship to data objects, certain notions orconcepts regarding such objects are appreciated. First, the concept of“visibility” implies that a data object is “known” to other componentsor collaborators. Similarly, the concept of “ownership” implies adetermination of which component has primary responsibility for thelifespan management of the data object. FIG. 1 illustrates the conceptsof visibility and ownership. It should be appreciated that in order forrelated components or collaborators to interact, an “object typespecification” or class for each data object employed in an interactionbetween collaborators must be known among all collaborators that makeuse of those data objects. In the present example of FIG. 1, anexemplary “eLearning component” 100 must include an object typespecification for exemplary person objects 102 and course objects 104 inorder to use the instances of person and course during collaboration.

[0008] By way of example, an object type specification must declare thepublicly accessible features of an object which may include data itemsand collaboration points. Of general interest during collaboration aredata items which are often called or known as attributes or fields.Generally speaking, data items represent the internal state of anobject. For example, FIG. 2 illustrates an object type specification ofa person object 102 as defined by a person object type specification 120which specifies that a person is composed of a first name, last name,social security number, date of birth, phone number, and mailing addressdata items. Additionally, an address object is comprised of an addressobject type specification 130 composed of street address, county, city,state, country, and postal code data items. In the example, the twoobject type specifications, 120 and 130, are related since the personobject type specification 120 includes as a data item and address objecttype specification 130. In other words, the two object typespecifications are related because the person class “has” an address.

[0009] In typical programming, it is commonplace for another componentin the same system to have requirements for the same information asalready specified in a first component, but in a different composition.For instance, FIG. 3 illustrates an exemplary phone book componenthaving an object type specification 140 that is defined to include dataitems common from both person object type specification 120 and addressobject type specification 130. In such a scenario, one or the other ofthe components is chosen for modification in order to avoid thecomplexity of maintaining redundant sets of objects in two separatecomponents. In such a scenario, the components are dependent on thecomposition of data objects as specified by the collaborator.

[0010] In prior attempts, others have attempted to achieve a similareffect by producing “adapter objects” which may contain references toone or more other objects that are called in order to fulfill therequests that are made on the adapter. For example, FIGS. 4 and 5illustrate two components in a system, a Person component 150 and aPhone Book component. Each of the components are in need of “person”data. In order to reduce the need for maintaining two sets of objectsthat must be synchronized, it is possible to implement the Phone BookPerson object 160 such that it can make use of the existing Personobject 150.

[0011] Therefore, it would be desirable to be able to specify an objecttype specification such that data items making up the state of theobject are supplied by other objects in the system.

BRIEF SUMMARY OF THE INVENTION

[0012] The present invention solves the need for virtual objects byproviding a mechanism for sharing data items with trusted collaboratorssuch that virtual objects may be declared and requested, constructed andretrieved. The present invention provides a mechanism for creatingobject-type specifications for virtual and partially virtual objects.Present invention further provides object-type specifications whereinvirtual objects may specify an external source for their internal state.This virtual state of an object may come from more than one externalsource. Furthermore, when a virtual state is obtained from multipleexternal sources, the associations among the sources may be specified ina manner that may be thought of as joinery. Furthermore, instances ofvirtual objects are immutable in order to protect the source objectsfrom data transformations that may violate the source objects'integrity. Additionally, the present invention provides a generic classfactory for obtaining instances of virtual objects.

[0013] The present invention provides a method for (1) creating objecttype specifications for virtual objects, (2) registering object-typespecifications for all objects that participate in virtual objects, and(3) providing an object factory where collaborators can obtain virtualobjects as needed. With regard to creating object-type specificationsfor virtual objects, the present invention maps the data item of oneobject to the data item of another object through the use of a query ofrun-time type-information (RTTI) to obtain the complete metadata forboth objects which must be known. The present invention provides anextension of existing deficiencies in programming language primitives byproviding utility and adaptor classes that may be used to indicate theadditional information necessary for object-to-object mappings.

[0014] These and other objects and features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] To further clarify the above and other advantages and features ofthe present invention, a more particular description of the inventionwill be rendered by reference to specific embodiments thereof which areillustrated in the appended drawings. It is appreciated that thesedrawings depict only typical embodiments of the invention and aretherefore not to be considered limiting of its scope. The invention willbe described and explained with additional specificity and detailthrough the use of the accompanying drawings in which:

[0016]FIG. 1 illustrates a component diagram demonstrating a sharing ofobjects;

[0017]FIG. 2 illustrate an object type specification of several objects;

[0018]FIG. 3 illustrates an object type specification derived from otherobjects;

[0019]FIG. 4 illustrates an object type specification through the use ofadapter objects;

[0020]FIG. 5 is a flow diagram of the adapter-type definition of anobject type specification as illustrated in FIG. 4;

[0021]FIG. 6 is a sequence diagram of the method for mapping a data itemof one object to the data item of another object through the use ofmetadata and extended metadata, in accordance with the preferredembodiment of the present invention;

[0022]FIG. 7 is a hierarchy diagram of an object having a relationshipwith another object;

[0023]FIG. 8 is a sequence diagram representative of a specificimplementation of the present invention;

[0024]FIG. 9 illustrates two objects exhibiting commonality in that oneobject is introduced by another and may rely upon the virtual objectmapping method, in accordance with the present invention; and

[0025]FIG. 10 illustrates the collaboration triggered by a request foran instance of an object, in accordance with a preferred embodiment ofthe present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] The present invention solves the need for virtual objects byproviding a mechanism for sharing data items with trusted collaboratorssuch that virtual objects may be declared and requested, constructed andretrieved. The present invention provides a mechanism for creatingobject-type specifications for virtual and partially virtual objects.The present invention further provides object-type specificationswherein virtual objects may specify an external source for theirinternal state. The virtual state of an object may come from more thanone external source. Furthermore, when a virtual state is obtained frommultiple external sources, the associations among the sources may bespecified in a manner may be thought of as joinery. Furthermore,instances of virtual objects are immutable in order to protect thesource objects from data transformations that may violate the sourceobjects' integrity. Additionally, the present invention provides ageneric class factory for obtaining instances of virtual objects. Thepresent invention provides a method for (1) creating object typespecifications for virtual objects, (2) registering object-typespecifications for all objects that participate in virtual objects, and(3) provide an object factory where collaborators can obtain virtualobjects as needed.

[0027] With regard to creating object-type specifications for virtualobjects, the present invention maps the data item of one object to thedata item of another object through the use of a query of run-timetype-information (RTTI) to obtain the complete metadata for both objectswhich need be known. The present invention provides an extension ofexisting deficiencies in programming language primitives that provideobject-to-object mappings through utility and adaptor classes that maybe used to indicate the additional information necessary forobject-to-object mappings.

[0028]FIG. 6 illustrates the afore-described mapping of such animplementation. FIG. 6 illustrates a flow diagram for extending themetadata which in the exemplary embodiment relies upon RTTI. In FIG. 6,a class definition factory 200 provides a facade class that allowsaccess to the extended metadata. The metadata is available per objecttype specification (class.) Class definition 210 is an encapsulation ofthe metadata for the use by the class factories and providers of virtualobjects. This class maintains a list of data items, also interchangeablyreferred to as “fields” or “attributes,” in an attribute array object220.

[0029] In the exemplary implementation, class definition 210 queries theRTTI for the metadata already known about the class. Class definition210 performs the task of extending the metadata and further defining theclass. Class definition 210 carries out the following steps:

[0030] 1. In step 212, Class Definition object 210 constructs anAttribute Array object 220 to hold the attribute objects.

[0031] 2. Class Definition object 210 identifies each class in a classhierarchy in a step 214; that is to say, Class Definition object 210identifies super classes within the class hierarchy.

[0032] 3. For each class in the hierarchy, Class Definition object 210in a step 216 constructs a Class Generation object 218 which in turnbuilds a list of attributes and adds them to the attribute array 220.

[0033] 4. Class Definition object 210 constructs an instance of theclass being further defined in a step 222 and a step 224.

[0034] 5. Class Definition object 210 in a step 226 asks the class todescribe itself.

[0035] 6. Class Definition object 210 in a step 228 prepares theattributes according to the extended metadata.

[0036] 7. Class Generation object 218 represents a particular generationin the class hierarchy. For instance, in FIG. 7, the Employee object 300is a specialization of Person object 310 which is the classic “is a”relationship, as depicted in FIG. 7, wherein Employee is a subclass ofPerson. By way of example, if Class Definition object 210 encounteredthe Employee object type specification, it would construct two ClassGeneration objects, one for Employee and one for the super class Person.

[0037] 8. Class generation 218 interrogates RTTI to determine which dataitems are introduced by the class that it represents. For each data iteminstructed, an attribute object 230 is added to the attribute array 220supplied by the Class Definition object 210.

[0038] Returning to FIG. 6, the attribute object 230 represents a dataitem that is specified for a particular generation of class. In anembodiment that employs RTTI, information relating to the name of thedata item which, for example, in FIG. 7 is the social security number,position, salary, or boss of the employee class, the type of the dataitem including the specific data type and whether such type is aprimitive or abstract.

[0039] Additionally, Attribute object 230 of FIG. 6 includes theoperations necessary to extend the metadata. Such extensions include:1—Calculated, 2—External, 3—Nullible, 4—Indexed, and 5—Primary. Thecalculated extension is a descriptor that indicates that the attributerepresents a calculated value and does not have an external sourcealthough the attribute itself may be an external source. The externalextension is a descriptor that indicates the attributes represent acalculated value and does not have an external source although theattribute itself may be an external source. The external descriptor is adescriptor that indicates the attribute has an external source and istherefore virtual in nature, meaning that its value is owned by anotherobject and mapped to the present object under construction. The nullableextension is a descriptor that indicates that “non-value” is a validvalue for the attribute. The index extension is a descriptor thatindicates that the attribute will be used in constraints used to obtaininstances of the virtual object. The primary extension is a descriptorthat indicates that the attribute is indexed and that it participates inuniquely distinguishing among other object instances.

[0040] Still referring to FIG. 6, Attribute Array object 220 is acontainer object created by the Class Definition object 210 and sharedby Class Definition object 210 and Class Generation object 218 in orderto maintain the extended metadata for a class.

[0041] The metadata extension as depicted in FIG. 6 further includes aDescribable object 240 which functions as an “interface” that enables aclass for interrogation. Through the Describable object 240 interface,the Class Definition object 210 can call back to an instance of theclass itself to supply the additional metadata. In this manner, theauthor of the class maintains responsibility for the definition andbehavior of the class. FIG. 6 further illustrates a “describe yourself”method call 226 which, for example, assumes the objects introduced inFIG. 7. In this particular message sequence, the Employee class isillustrated as extending the metadata to indicate that the “salary” dataitem is a virtual data item. Returning to FIG. 6, regarding theDescribable object 240, in method call 224, Class Definition object 210constructs a new instance of the class being described by thecollaboration. In a method 226, Class Definition object 210 calls the“describe yourself” method implemented by the class being described andpasses in a reference to itself so that the class has access tometadata.

[0042]FIG. 8 illustrates the sequence diagram for the “describeyourself” method call 226 which for example assumes the objectsintroduced in FIG. 7. In this particular message sequence, the Employeeclass is illustrated as extending the metadata to indicate that the“salary” data item is a virtual data item. In the present example ofFIG. 8, the Employee class calls the “add external join” method 442implemented by the Class Definition object 210 to indicate that it canbe associated with instances of the “Employee Salary” class 320 (FIG. 7)that match its “social security number” data item. In a method call 444,employee class calls the “get attribute” method implemented by the ClassDefinition object 210 to obtain a reference to the “salary” attribute.In a method call 446, Class Definition object 210 calls the “get” methodimplemented by the Attribute Array object 420 to obtain a reference tothe “salary” attribute which it returns to the Employee object 440.

[0043] In method call 448, the Employee object calls the “set nullable”method of the Attribute object 430 to indicate that the salary attributeis an optional data item meaning that no-value is valid. In a methodcall 450, the Employee object calls the “set attribute source” methodimplemented by the Class Definition object 210 to indicate that thesalary attribute is a virtual and therefore external data item to beretrieved from an instance of “employee salary” if one exists thatmatches the joinery established in method call 442. In method call 452,the class definition object 210 calls the “set external” method of theattribute object 430 to indicate that the salary attribute is external.

[0044] It should be noted that the method calls depicted in FIG. 8 areused as an example of a representation of the Java implementation forconveying an example indicative of the present invention, while otherimplementations are also contemplated within the scope of the presentinvention. Furthermore, the “describable” interface described above isnot a requirement for obtaining a class definition meaning an extensionof the metadata for an object type specification but is rather includedfor an example of how an interface may be implemented.

[0045] It should be recalled that operation of the present inventioninvolves creating an object type, which has been described above andalso registering the object type specifications for all objects thatparticipate in virtual objects. The complete and extended metadata forall virtual object participants must be known by the Object Factoryobject 600 in order to facilitate the construction and composition ofvirtual objects. To make such complete metadata available, the presentinvention employs an object registry 500 (FIG. 8) for this purpose.

[0046] Due to the nature of virtual objects, a mechanism must exist thatcan construct and compose these objects from the other objectsavailable. The present invention employs a component called an ObjectFactory for such a purpose. An Object Factory differs from a classfactory in that it can construct and obtain objects of any typeregistered with the virtual object system as long as a unique piece ofinformation is known about the object to be retrieved. For example,consider the two objects in FIG. 9, an Employee object and a Personobject. FIG. 9 illustrates an Employee object introduced by onecomponent and a Person object introduced by another component. Inexamples such as this, where there is an integration to be built betweentwo components that have similar object structures, virtual objectsprovide a means by which redundancies can be reduced. Such a reductionis particularly important when objects need to persist betweenexecutions.

[0047]FIG. 10 illustrates the collaboration triggered by a request foran instance of the Employee object from FIG. 7. It is important tounderstand that Employee is a pure virtual object, meaning that it doesnot own any of its own data items. This is a simple case for the sake ofillustration as a virtual object generally will be composed of dataitems from more than one object, and such is contemplated within thescope of the present invention.

[0048] Returning to FIG. 10, an employee with the social security numberof 111-222-3333 is being requested. In the present example of FIG. 10,an object calling the “find” method of the Object Factory 600 initiatesthe process in a step 602. In a step 604, the Object Factory 600maintains a keyed list of Providers, one for each class that isregistered. For virtual classes, the provider is supplied by the virtualobject system. If the class is not a virtual class, the provider isplugged into the Object Factory 600 so that it can call back to theowner of the class to obtain instances. In either case, the ClassDefinition Factory component 200 has a Class Definition for the class.The Object Factory 600 checks to see if there is a Provider for theclass requested by calling the “get” provider method.

[0049] Following the method call 604, a method call 606 finds the ObjectFactory component 600 delegating the “find” request to the provider. Ina method call 608, depending on the provider implementation, theProvider object 570 checks in object cache to see if there is an objectalready composed that would fulfill the request. This checking isaccomplished by calling the “get” method of the cache. If there is suchan object then it is returned from the cached object 580.

[0050] A method call 610 is implemented when the object did not exist,such as in the case of Employee, the Provider object 570 calls its own“make” method in order to create or retrieve one. In a method call 612,the Provider object 570 either maintains a reference to the ClassDefinition for the classes for which it provides, or obtains them fromthe Class Definition Factory 200 as needed. Provider object 570 calledthe “get external join count” method in order to determine how manyclasses the Employee Class has associated therewith.

[0051] The following loop, defined herein as loop 1, having thereference numeral 620 is performed for each associated class as a joinfunction. In a method call 622, the Provider object 570 retrieves thenext Join object 624 from the Class Definition object 580 by calling the“get external join” method. In a method call 626, the Provider object570 retrieves the target of the association represented by the Joinobject 624 by calling the “get join class” method of the Join object624. In a method call 628, a provider object 570 retrieves from the Joinobject 624 the number of attributes that participate in the join bycalling the “get attribute count.” The obtained attributes are theattributes of the Employee that have an associated attribute on thetarget of the association.

[0052] For each of the participating attributes, a loop 630 isperformed. In loop 630, a method call 632, initiated by the Providerobject 570, retrieves from the Join object 624 the next Join Attributeby calling the “get attribute” method. Join attributes represent eachspecific attribute that participates in the join. Loop 630 furtherincludes a method call 634 wherein the Provider object 570 retrievesfrom the Join attribute the local attribute by calling the “getattribute” method. Loop 630 further includes a method call 634 whereinthe Provider object 570 retrieves from the Join attribute the localattribute by calling the “get” method. From the perspective of a join,attributes are either local or external. Local attributes are thosedefined in the current classes, while external attributes are those atthe other end of the association. It should be pointed out that if thename of the local attribute matches one of the find conditions given,the value given in the find condition is communicated to the Attributeby a call to the “set value.” Loop 630 further comprises a method call636 wherein the Provider object 570 retrieves a conditional statementfrom the Attribute object 638. One exemplary implementation of theObject Factory component 600 and Provider objects 570, support SQL/92syntax or other similar syntax for conditional statements. In thepresent example, we consider a conditional statement as part of an SQLstatement following the “where” clause in the outer statement.

[0053] Following the interactive approach of Loop 630, a method call 640issued by Provider object 570 to Object Factory component 600 retrievesany associated objects and provides decoupling of componentsparticipating in virtual objects by reducing the explicit knowledge thateach must know about providers of objects which are typicallycomponents. In method call 640, Provider object 570 calls the “find”method of the Object Factory component 600 to obtain the joined object.The Provider object passes the class obtained in method call 626 so thatthe Object Factory component 600 can retrieve the desired type of objectand the conditional statement constructed in loop 630.

[0054] If method call 640 returns an object, in this case a Person, thenthe Provider object 570 proceeds with constructing a new virtual object.In FIG. 10, such a construction is indicated by the Provider object 570calling a “compose from” method on itself. In a method call 644, theProvider object constructs a new “hollow” Employee object 646. In amethod call 648, the Provider object 570 uses the Class DefinitionFactory 200 to obtain the Class Definition from the “join object”object. In a method call 650, Provider object 570 uses the ClassDefinition in the present example for Employee to determine the numberof attributes that are defined.

[0055] An iterative loop 652 is executed for each defined attribute. Ina method call 654, Provider object uses the Class Definition, in thepresent example for Employee, to obtain the next defined attribute bycalling the “get attribute” method. In a method call 656, the Providerobject uses Class Definition, in the present example for Employee, toobtain the external source definition for the attribute by calling the“get attribute source” method, passing the attribute returned frommethod call 654. The external source is represented by an ExternalAttribute object 658. In a method call 660, Provider object 570 uses theExternal Attribute object 658 to obtain the class of the externalattribute source. In a method call 662, if the current join classobtained in method call 626 and the attributes source from method call660 refer to the same class, then the Provider object 570 calls in aninternal method called “get attribute value” to establish a value forthe attribute retrieved in a method call 654.

[0056] In a method call 664, the Provider object uses the ExternalAttribute object 658 to obtain the name of the source attribute on theexternal object. In a method call 666, the Provider object 570 uses theclass definition object for Person to obtain the source attribute bycalling the “get attribute” method. The result of method call 640, inthe present example join object, is used as a first parameter. Thisparameter indicates the external object from which to take theattribute. The resulted method call 664 is used as the second parameter.This parameter indicates which attribute should be retrieved.

[0057] In method call 670, provider object 570 uses the attribute fromPerson object 672 to obtain a value object by calling the “get value”method. In a method call 674 provider object 570 establishes a new valuefor the attribute retrieved from employee in method call 654 by callingthat object's “set value” method which concludes processing of loop 652.

[0058] In a method call 676, depending upon the provider objectimplementation, the provider object may optionally retain a reference toa requested object in an Object Cache 580. Such an approach isaccomplished by calling the “put” method of the Cache.

[0059] The present invention solves the need for virtual objects byproviding a mechanism for sharing data items with trusted collaboratorssuch that virtual objects may be declared and requested, constructed andretrieved. The present invention provides a mechanism for creatingobject-type specifications for virtual and partially virtual objects.The present invention further provides object-type specificationswherein virtual objects may specify an external source for theirinternal state. The virtual state of an object may come from more thanone external source. Furthermore, when a virtual state is obtained frommultiple external sources, the associations among the sources may bespecified in a manner may be thought of as joinery. Furthermore,instances of virtual objects are immutable in order to protect thesource objects from data transformations that may violate the sourceobjects' integrity. Additionally, the present invention provides ageneric class factory for obtaining instances of virtual objects. Thepresent invention provides a method for (1) creating object typespecifications for virtual objects, (2) registering object-typespecifications for all objects that participate in virtual objects, and(3) provide an object factory where collaborators can obtain virtualobjects as needed.

What is claimed is:
 1. A method for creating a virtual object having atleast one data item derived from first object, comprising the steps of:a. defining a class definition object to provide access to metadata andextended metadata, said extended metadata facilitating mapping betweensaid at least one data items of said another object and virtual dataitems of said virtual object; and b. for each of said virtual data itemsof said virtual object, establishing a mapping between said virtual dataitems of said virtual object and said at least one data item of saidfirst object.
 2. In a object oriented program, a method for mapping atleast one attribute of at least one data item from a first object to avirtual object having a virtual class, comprising the steps of: a.defining a class factory object to provide access to metadata andextended metadata, said extended metadata facilitating mapping betweenfirst attributes of said first object and virtual attributes of saidvirtual object; and b. defining a class definition object comprised ofsaid metadata for use by said class factory object in providing saidvirtual object.
 3. The method, as recited in claim 2, wherein saiddefining said class definition object comprises the step of: a.constructing an attribute array object to hold said virtual attributesof said virtual object.
 4. The method, as recited in claim 3, whereinsaid defining said class definition object comprises the steps of: a.identifying each class in a class hierarchy of said virtual class ofsaid virtual object; and b. for each of said class in said classhierarchy, i. constructing a class generation object which builds a listof said virtual attributes and adds said virtual attributes to saidattribute array object.
 5. The method, as recited in claim 4, whereinsaid constructing a class generation object further includes: a.querying said metadata and said extended metadata for each of saidvirtual attributes; and b. constructing an attribute object and addingsaid attribute object to said attribute array object.
 6. The method, asrecited in claim 5, wherein said extended metadata includes: a. acalculated descriptor that indicates that said virtual attributerepresents a calculated value; and b. an external descriptor thatindicates that said virtual attribute has an external source.
 7. Themethod, as recited in claim 6, wherein said extended metadata furtherincludes: a. a nullable descriptor that indicates that said virtualattribute has null as a valid value for said virtual attribute; and b.an indexed descriptor that indicates that the attribute will be used inconstraints used to obtain instances of said virtual object.
 8. Themethod, as recited in claim 4, wherein said defining said classdefinition object comprises the step of: a. constructing an instance ofsaid virtual class.
 9. The method, as recited in claim 8, wherein saiddefining said class definition object comprises the steps of: a.populating said instance of said virtual object with said metadata; andb. preparing said virtual attributes of said virtual object as directedby said extended metadata.
 10. The method, as recited in claim 2,wherein said method for mapping further comprises the step of: a.registering said metadata and said extended metadata or said virtualobject in an object registry for access by said object factory objectfor construction and composition of other objects.
 11. Acomputer-readable medium having computer-executable instructions formapping at least one attribute of at least one data item from a firstobject to a virtual object having a virtual class, said instructionsperforming the steps of: a. defining a class factory object to provideaccess to metadata and extended metadata, said extended metadatafacilitating mapping between first attributes of said first object andvirtual attributes of said virtual object; and b. defining a classdefinition object comprised of said metadata for use by said classfactory object in providing said virtual object.
 12. Thecomputer-readable medium, as recited in claim 11, comprisingcomputer-executable instructions for performing the step of definingsaid class definition object, further comprises computer-executableinstructions for performing the step of: a. constructing an attributearray object to hold said virtual attributes of said virtual object. 13.The computer-readable medium, as recited in claim 12, comprisingcomputer-executable instructions for performing the step of definingsaid class definition object, further comprises computer-executableinstructions for performing the steps of: a. identifying each class in aclass hierarchy of said virtual class of said virtual object; and b. foreach of said class in said class hierarchy, i. constructing a classgeneration object which builds a list of said virtual attributes andadds said virtual attributes to said attribute array object.
 14. Thecomputer-readable medium, as recited in claim 13, wherein saidcomputer-executable instructions for performing the step of constructinga class generation object further includes computer-executableinstructions for performing the steps of: a. querying said metadata andsaid extended metadata for each of said virtual attributes; and b.constructing an attribute object and adding said attribute object tosaid attribute array object.
 15. The computer-readable medium, asrecited in claim 14, wherein said computer-executable instructions fordefining said class definition object further includescomputer-executable instructions defining said extended metadata toinclude: a. a calculated descriptor that indicates that said virtualattribute represents a calculated value; and b. an external descriptorthat indicates that said virtual attribute has an external source. 16.The computer-readable medium, as recited in claim 15, wherein saidcomputer-executable instructions for defining said class definitionobject further includes computer-executable instructions defining saidextended metadata to include: a. a nullable descriptor that indicatesthat said virtual attribute has null as a valid value for said virtualattribute; and b. an indexed descriptor that indicates that theattribute will be used in constraints used to obtain instances of saidvirtual object.
 17. The computer-readable medium, as recited in claim13, wherein said computer-executable instructions for performing thestep of defining said class definition object comprisescomputer-executable instructions for performing the step of: a.constructing an instance of said virtual class.
 18. Thecomputer-readable medium, as recited in claim 17, wherein saidcomputer-executable instructions for performing the step of definingsaid class definition object comprises computer-executable instructionsfor performing the steps of: a. populating said instance of said virtualobject with said metadata; and b. preparing said virtual attributes ofsaid virtual object as directed by said extended metadata.
 19. Thecomputer-readable medium, as recited in claim 11, wherein saidcomputer-executable instructions for performing the step of mappingfurther comprises computer-executable instructions for performing thestep of: a. registering said metadata and said extended metadata or saidvirtual object in an object registry for access by said object factoryobject for construction and composition of other objects.